万字长文：监控系统选型分析及误区探讨
本文摘自于朱政科撰写的《Prometheus云原生监控：运维与开发实战》，重点介绍了在监控系统选型中应该考虑的问题。在本文中，你将会了解监控应用程序的黑盒和白盒方法，也会了解监控执行检查的拉取和推送方式，还会了解常见的监控系统以及进行监控系统选型时应该注意的问题
《SRE: Google运维解密》一书中指出，监控系统需要有效支持白盒监控和黑盒监控；还有一种类似的观点认为，监控系统必须支持探针（Probing）和内省（Introspection）。
黑盒监控，对应探针的概念，常见的有HTTP探针、TCP探针等，可以在系统或者服务发生故障时快速通知相关人员进行处理。探针位于应用程序的外部，通过监听端口是否有响应且返回正确的数据或状态码等外部特征来监控应用程序。Nagios就是一个主要基于黑盒/探针的监控系统。
白盒监控，对应内省的概念，通过白盒能够了解监控对象内部的实际运行状态，通过对监控指标的观察能够预判可能出现的问题，从而对潜在的不确定因素进行优化。白盒监控可以直接将事件、日志和指标发送到监控工具，它具有比黑盒监控更丰富的应用程序上下文信息。MDD理念主要对应的就是基于白盒的监控系统。
监控系统执行监控检查的模式主要有拉取（Pull）和推送（Push）两种。这两种模式究竟哪种更好？对此，监控领域内部存在相当大的争议。
拉取模式（简称拉模式），是一种从监控对象中通过轮询获取监控信息的方式。拉模式更多拉取的是采样值或者统计值，由于有拉取间隔，因此并不能准确获取数值状态的变化，只能看到拉取间隔内的变化，因此可能会产生一些毛刺现象，需要进一步进行数据处理。监控和性能测试更关注p95/p99位的原因就是存在长尾效应。数据采集过程中对数据进行的定义、采样、去尖刺等处理操作也是非常重要的，这部分内容我们会在后续章节详细介绍。
拉模式的优点是告警可以按照策略分片，告警模块只需要拉取自己需要的数据，且可以完美支持聚合场景；拉模式的缺点在于监控数据体量非常庞大，对存储有较高的要求，实战中可能还需要考虑数据的冷热分离。
推送模式（简称推模式），是应用程序基于事件主动将数据推向监控系统的方式。推模式的优点是实时性好，一旦触发一个事件就可以立刻收集发送信息。但是推模式的缺点也很明显，由于事件的不可预知性，大量的数据推送到监控系统，解析和暂存会消耗大量的内存，这可能对监控的进程产生影响。由于消息是推送过来的，所以主动权在推送方。在这种模式下，由于网络等迟迟没有得到确认，所以在ack等情况下很容易造成数据重复。这是因为推模式在进行推送中，如果发送失败，为了防止内存撑爆，系统会将数据持久化到文件或者队列。因此采用推模式时，若产生了重复数据，就需要进行去重等操作，对于这些技术细节，需要仔细打磨。
Prometheus在收集数据时，主要采用拉模式（服务端主动去客户端拉取数据），当然它也支持接收推送到Pushgateway的事件；而以Zabbix为代表的传统监控系统采用推模式（客户端发送数据给服务端）。拉模式在云原生环境中有比较大的优势，原因是在分布式系统中，一定是有中心节点知道整个集群信息的，那么通过中心节点就可以完成对所有要监控节点的服务发现，此时直接去拉取需要的数据就好了；推模式虽然可以省去服务发现的步骤，但每个被监控的服务都需要内置客户端，还需要配置监控服务端的信息，这无形中加大了部署的难度。推模式在OpenStack和Kubernetes等环境中使用比较少。
有些技术人员常说：“我刚接触监控的时候就已经是Prometheus的时代了，我都没有接触过Nagios、Zabbix这些上古监控系统。”那么，在Prometheus之前，常见监控系统都是怎样的呢？让我们一起来了解一下。
1. Nagios
Nagios原名NetSaint，是Nagios Ain’t Gonna Insist On Sainthood的缩写，Sainthood译为圣徒，而Agios是saint希腊语的表示方法。它是由Ethan Galstad开发并维护的一款开源且老牌的监控工具，用C语言编写而成。Nagios虽然开发时被定义为在Linux下使用，但在UNIX下也工作得非常好。
在涉及开源监控时，Nagios会被一些人认为是“行业标准”，这在某种程度上是正确的，因为Nagios是第一个真正称得上专业的监控系统。在Nagios之前，虽然也有一些监控工具，但是这些工具都太“业余”了，以至于它们根本无法与1999年推出的Nagios相提并论。Nagios是监控领域的第一个跨时代产品，且拥有最大的社区和非常多的Fork，如OpsView、OP5、Centreon、Icinga、Naemon、Shinken等。有过多的Fork，意味着在应用插件或工具时会造成混乱，因为每个分支都有不同的理念，随着时间的推移，这使得Nagios与其他分支、父项目（Nagios）出现不兼容的现象。
Nagios能有效监控Windows、Linux和UNIX的主机状态（CPU、内存、磁盘等），以及交换机、路由器等网络设备（SMTP、POP3、HTTP和NNTP等），还有Server、Application、Logging，用户可自定义监控脚本实现对上述对象的监控。Nagios同时提供了一个可选的基于浏览器的Web界面，以方便系统管理人员查看网络状态、各种系统问题以及日志等。
如图1-8所示，Nagios的核心架构主要由Nagios Daemon、Nagios Plugins和NRPE这3个模块构成。
由图1-8可知：
1）Nagios Daemon作为系统的核心组件，负责组织与管理各组件，协调它们共同完成监控任务，并负责监控信息的组织与展示。
2）Nagios Plugins主要指Nagios核心组件自带的组件，还包括一些用户自开发的插件。这些组件监控各项指标，并将采集到的数据回送给Nagios服务器。
3）NRPE（Nagios Remote Plugin Executor）是安装在监控主机客户端上的代理程序（Linux系统是NRPE软件）。通过NRPE可获取监控数据，这些数据会被再回送给Nagios服务器。默认使用的端口是5666。
Nagios以监控服务和主机为主，但是它本身不包括这部分功能，是通过“插件”生态系统或第三方功能来实现的。在主动模式中，Nagios不需要调用客户端的插件，而是通过自己的插件主动探测客户端的相关信息；在被动模式中，Nagios通过启动客户端上的NRPE来远端管理服务。启动Nagios后，它会周期性自动调用插件以检测服务器状态，同时会维持一个队列，所有插件返回的状态信息都会进入该队列，Nagios每次都会从队首读取信息，处理后再将状态结果呈现出来。被动模式的具体流程如下（见图1-9）。
1）Nagios执行安装在它里面的check_nrpe插件，并告诉check_nrpe检测哪些服务。
2）通过SSL, check_nrpe连接远端机器上的NRPE Daemon。
3）NRPE运行本地的各种插件来检测本地的服务和状态。
4）NRPE把检测结果传给主机端check_nrpe, check_nrpe再把结果送到Nagios状态队列中。
5）Nagios依次读取队列中的信息，再把结果显示出来。
Nagios会将获取的数据保存在环形数据库（Round Robin Database，RDD）中。RDD是一种循环使用存储空间的数据库，适用于存储和时间序列相关的数据。RDD数据库在创建的时候就会定义好大小并使数据存储空间形成圆环状，每个数据库文件都以.rdd为后缀，指针指向最新的数据位置并随着数据读写移动。如果没有获取到最新数据，RDD就会使用默认的unknown填充空闲空间，以保证数据对齐。当空间存储满了以后，又从头开始覆盖旧的数据，所以和其他线性增长的数据库不同，RRD的大小可控且不用维护。
Nagios出现于20世纪90年代，它的思想仍然是通过复杂的交错文本文件、脚本和手动程序进行管理，基于文本文件的配置每次进行更改时都需要进行重置，这也使得在文件分布复杂的情况下必须借助第三方工具（例如Chef或Puppet）进行部署，因此Nagios如何进行有效配置管理是一个瓶颈。为了使用Nagios监控，有必要熟练掌握处理数百个自定义脚本的方法，若这些脚本由不同的人采用不同的风格编写，那么处理脚本的过程几乎会变成某种“黑魔法”。对很多人来说，管理Nagios是非常复杂的，这最终导致Nagios成为软件与定制开发之间的奇怪组合。
Nagios（以及它的一些较新的分支，如Naemon）仍然使用C编写的CGI。这项技术是在20世纪80年代发明的，对其进行扩展或改进会很复杂，哪怕进行简单更改，都需要对整体架构代码打补丁并手动编译。Nagios生态系统是基于每个Fork的不同版本的数百个不同补丁建立的，它简直就是一个集市，是“集市”模式的范例；而Zabbix和Pandora FMS则恰恰相反，是“大教堂”模式，是模块化的可靠项目，在架构师团队的指导下正在不断发展。
2. Zabbix
Zabbix是一款拥有超过21年的历史、100%免费开源、全世界安装次数超过30万的监控软件（截至2019年），旨在从成千上万的服务器、虚拟机和网络设备中收集指标进行监控，是适用于绝大多数IT基础架构、服务、应用程序、云、资源等的解决方案。Zabbix长期以来一直在瓜分Nagios的蛋糕，但它是一个成熟的系统，而不是简单的Nagios的分支，它的主要特征是对监控具有非常全面的视角，而不是仅仅监控状态，这恰是Nagios存在严重不足的地方。Zabbix的配置文件也不像Nagios那么复杂。
Zabbix是由Alexei Vladishev开源的分布式监控系统，和Nagios一样提供集中的Web管理界面。Zabbix有着非常酷炫的新版官网和详细的文档使用手册，企业级的Zabbix具有无限扩展、分布式监控、高可用、强大的安全性等特性。在本书截稿时，Zabbix 4.4版本刚刚发布，这个版本用Go语言编写了全新的Zabbix代理，为Zabbix模板设置了标准，除了为MySQL、PostgreSQL、Oracle、DB2新增了TimescaleDB这种具有线性性能的数据库以外，还提供了高级可视化选项，以及一键式云部署等功能。
图1-10是Zabbix的架构图，Zabbix可以通过Agent及Proxy的形式（见图1-11），比如JVM Agent、IPMI Agent、SNMP Agent等采集主机性能、网络设备性能、数据库性能的相关数据，以及FTP、SNMP、IPMI、JMX、Telnet、SSH等通用协议的相关信息，采集信息会上传到Zabbix的服务端并存储在数据库中，相关人员通过Web管理界面就可查看报表、实时图形化数据、进行7×24小时集中监控、定制告警等。
3. Ganglia
Ganglia直译为神经节、中枢神经，这一名称其实已经反映了作者的设计思路，即将服务器集群理解为生物神经系统，每台服务器都是独立工作的神经节，这些神经节通过多层次树突结构联结起来，既可以横向联合，也可以从低到高逐层传递信息。具体例证就是Ganglia的收集数据可以工作在单播（unicast）或多播（multicast）模式下（默认为多播模式）。很多通过cacti或者Zabbix看不出来的集群总体负载问题，都能在Ganglia中体现，其集群的熵图可以明确集群负载状况，这是Ganglia最大的亮点。
Ganglia是加州大学伯克利分校发起的一个为HPC（高性能计算）集群而设计的开源、可扩展、分布式监控系统，用于测量数以千计的节点。作者于2000年在伯克利分校网站上分享了源码。Ganglia是BSD许可的开源项目，源于加利福尼亚大学的伯克利千年项目，最初是由美国国家高级计算基础设施合作伙伴（NPACI）和美国国家科学基金会RI奖EIA-9802069资助的。Ganglia用于大规模的集群和分布式网格等高性能计算系统。基于XML技术的数据传递可以使系统的状态数据跨越不同的系统平台进行交互，且采用简洁紧凑的XDR方式实现监控数据的压缩和传输。它主要用于实时查看Linux服务器和集群（图形化展示）中的各项性能指标，让用户以集群（按服务器组）和网格（按地理位置）的方式更好地组织服务器。
Ganglia的核心包含gmond、gmetad以及一个Web前端，其主要用来监控系统性能，如CPU使用率、硬盘利用率、I/O负载、网络流量情况等，通过曲线很容易查看每个节点的工作状态，这对合理调整、分配系统资源，提高系统整体性能起到重要作用。Ganglia与Falcon、Zabbix相比，主要区别体现在集群的状态集显示上，Ganglia可以很便捷地对比各主机的性能状态。但随着服务、业务的多样化，Ganglia表现出一些不足：覆盖的监控面有限，且自定义配置监控比较麻烦，在展示页面查找主机烦琐，展示图像粗糙且不精确。
如图1-12所示，Ganglia通过gmond收集数据，数据传输到服务端gmetad，最后在PHP编写的Web UI界面Web前端进行展示。组件之间通过XDR（xml的压缩格式）或者XML格式传递监控数据，以达到监控效果。
图1-12所示的各个模块介绍如下：
gmond（Ganglia Monitoring Daemon）：双重角色，一方面作为Agent部署在需要监控的服务器上，另一方面作为收发机接收或转发数据包。可以将其理解为部署在每个监控服务器上的用于收集和发送度量数据的守护进程。
gmetad（Ganglia Meta Daemon）：负责收集所在集群的数据并持久存储到RRD数据库，支持水平扩展。
Web前端：Ganglia项目提供了一个由PHP编写的通用型Web包，可以将主要实现数据可视化，并能提供一些简单的数据筛选UI。页面不多，大量使用了模板技术。
Ganglia的主要优势反映在收集数据和集中展示数据方面。Ganglia可以将所有数据汇总到一个界面集中展示，并且支持多种数据接口，可以很方便地扩展监控，最为重要的是，Ganglia收集数据非常轻量级，客户端的gmond程序基本不耗费系统资源，而这个特点刚好弥补了Zabbix的不足。gmond带来的系统负载非常少，这使得它可以在集群中各台计算机上轻松运行，而不会影响用户性能。所有这些数据多次收集会影响节点性能。当大量小消息同时出现并造成网络“抖动”时，可以通过让节点时钟保持一致来避免这个问题。
Ganglia对大数据平台的监控更为智能，只需要一个配置文件，即可开通Ganglia对Hadoop、Spark的监控，监控指标有近千个，可以满足对大数据平台的监控需求。
和前面提到的Nagios一样，Ganglia的gmetad收集的时间序列数据通过RRD存储，RRDTool作为绘图引擎使用并生成相应的图形显示，以Web方式直观地提供给客户端。Ganglia也拥有灵活的数据标准和插件生态，可以很方便地在默认监控指标上引用或者定制其他扩展指标。这一特性在大数据领域也获得了认可，Hadoop、Spark等都开放了面向Ganglia的指标集，在GitHub上也有很多现成的扩展插件。
4. Open-Falcon
Falcon是猎鹰、隼的意思，鹰眼具有精准、洞穿的特点。Open-Falcon是小米开源的监控系统，是为了解决Zabbix的不足而出现的产物，它由Go语言开发而成，小米、滴滴、美团等超过200家公司都在不同程度上使用Open-Falcon。小米同样经历过Zabbix的时代，但是当机器数量、业务量上来以后（尤其是达到上万上报节点），Zabbix在性能、管理成本、易用性、监控统一等方面就有些力不从心了。Open-Falcon具有数据采集免配置、容量水平扩展、告警策略自动发现、告警设置人性化、历史数据高效查询、Dashboard人性化、架构设计高可用等特点。Open-Falcon的文档目前分为0.1和0.2版本，且每个版本都有中、英两个版本，社区贡献了MySQL、Redis、Windows、交换机、LVS、MongoDB、Memcache、Docker、Mesos、URL监控等多种插件支持，其架构如图1-13所示。
如图1-13所示，使用Open-Falcon需要在Linux服务器上安装Falcon-agent，这是一款用Go语言开发的Daemon程序，用于自发现且采集主机上的各种指标数据，主要包括CPU、磁盘、I/O、Load、内存、网络、端口存活、进程存活、ntp offset（插件）、某个进程资源消耗（插件）、netstat和ss等相关统计项，以及机器内核配置参数等指标，指标数据采集完成后主动上报。Falcon-agent配备了一个proxy-gateway，用户可以使用HTTP接口将数据推送到本机的Gateway，从而将数据转发到服务端。Transfer模块接收到Falcon-agent的数据以后，对数据进行过滤梳理以后通过一致性Hash算法发送到Judge告警判定模块和Graph数据存储归档模块。Heartbeat server（心跳服务）简称HBS，每个Agent都会周期性地通过RPC方式将自己的状态上报给HBS，主要包括主机名、主机IP、Agent版本和插件版本，Agent还会从HBS获取需要执行的采集任务和自定义插件。
Open-Falcon具有如下特性：
强大灵活的数据采集能力：自动发现，支持Falcon-agent、SNMP、用户主动推送、用户自定义插件、OpenTSDB类型的数据模型（timestamp、endpoint、Metric、key-value tags）。
水平扩展能力：支持每个周期上亿次的数据采集、告警判定、历史数据存储和查询。
高效率的告警策略管理：支持高效的portal、策略模板、模板继承和覆盖、多种告警方式、callback调用。
人性化的告警设置：最大告警次数、告警级别、告警恢复通知、告警暂停、不同时段不同阈值、维护周期。
高效率的Graph组件：单机支撑200万指标的上报、归档、存储（周期为1分钟）。
高效的历史数据query组件：采用RRDTool的数据归档策略，秒级返回关于上百个指标一年的历史数据。
Dashboard：多维度的数据展示，用户可自定义Screen。
高可用：整个系统无核心单点，易运维，易部署，可水平扩展。
开发语言：整个系统的后端全部用Golang编写，portal和Dashboard则用Python编写。
5. ZMon
如果公司规模较小，不需要Prometheus这种级别的监控系统，那么可以考虑使用荷兰电商Zalanado公司开源的ZMon这款天然的分布式监控及告警系统。ZMon和Prometheus一样，都采用拉模式，但需要在监控的目标上安装Check来抓取指标信息，这些Check都分布在一个个Python编写的Worker上，其可对目标和站点进行Check操作（类似于Prometheus中的Exporter的概念）。Worker采集到的数据在ZMon中采用KairosDB进行存储，KairosDB底层使用的是Cassandra进行存储。KairosDB支持Grafana集成、一般的计算函数、Tag级指标支持、Roll-up预聚合，适用于中大规模DevOps团队自治的场景。从左到右看图1-14所示的架构，ZMon更像是一个任务队列分发的分布式系统，图左侧的用户端生成一些Check和Alert的任务，通过队列分发给图右侧后端可以无限扩展的Worker，这些Worker执行程序检查目标，将告警和数据传递给用户端和存储层KairosDB。
ZMon具有如下特性：
支持自定义Check和Alert，团队之间可以共享Check，通过继承重用Alert并定制告警级别。
支持Dashboard和Grafana。可以根据团队和Tags定义带有小部件和告警过滤器的自定义仪表盘。由于是KairosDB存储，可以直接使用Grafana从KairosDB数据源中绘制数据仪表盘。
支持Python表达式。Check和Alert都是任意的Python表达式，提供了很大的灵活性和强大的功能。Python可以在平台部署中将很多底层任务和系统完美集成。
支持推送通知：支持推送技术订阅来实现自告警，可以向电脑桌面和手机发送提醒。
支持Rest API监控。收集应用程序的API指标之后，ZMon的云UI可以帮助用户直观地了解服务中正在发生的事情，可以呈现出不同的API路径以及相关指标。
支持对每个实体的告警进行概述。ZMon可以提供告警的全局视野以及每个实体的具体信息，每个实体也可以通过搜索的形式，显示映射到这些实体的所有告警及其当前状态。
支持试运行和即时评估。比如可以在UI页面始终执行Check和Alert，以试运行的形式快速获取反馈结果。
衡量一款监控系统是否符合需求，需要从多个维度进行考察。本节我们就从功能、性能、数据存储、服务发现、运维管理、开发语言、社区力度及生态发展、误区探讨这8个角度进行监控系统的选型分析。
1. 功能
首先就是功能维度，它直接决定了能否实现开箱即用，从而缩短项目周期、降低成本等。如果一款监控系统达不到想要的功能，那么就需要进行二次开发，这样会增加项目的技术难度、复杂度以及延长项目周期等。
表1-3从主要维度对主流监控系统做了评估。
比如在功能上，相对于Open-Falcon，为什么会出现滴滴内部的基于Open-Falcon的DD-Falcon？是因为在功能上DD-Falcon相比于Open-Falcon，主要进行了如下改进。
监控数据按服务单元分类。
增加垃圾数据清洗。
分级索引。
精简RRA。
巡检大盘支持同环比。
重组看图首页。
报警数据获取由推模式变为拉模式。
去除告警模板。
重新定义nodata。
2. 性能
功能维度是监控系统选型中的一个重要参考维度，但不是唯一的维度。有时候性能比功能还要重要，况且性能和功能很多时候是相悖的，鱼和熊掌不可兼得。
小米初期是使用Zabbix来做监控的。Zabbix大名鼎鼎，成熟稳健，很多公司都在使用。小米也不例外，初期做运维开发的人员比较少，机器量、业务量也少，Zabbix可以很好地满足需求。但是随着业务的发展，MySQL出现了性能瓶颈。由于Zabbix是使用MySQL来存放监控历史数据的，假设一台机器有100个监控项，2000台机器就有20万个监控项。监控系统的数据采集没有高峰低谷，是持续性的、周期性的，一般是1分钟采集一次。机器量越来越大，数据量就越来越大，MySQL的写入逐渐成为瓶颈。小米尝试使用了业界的一些Proxy的方案，也尝试把采集周期调长，比如3分钟采集一次或者5分钟采集一次，但是都治标不治本。Zabbix有些数据采集是通过拉的方式，也就是服务器端主动探测的方式，当目标机器量大了之后，拉任务也经常出现积压。这些问题直接导致维护Zabbix的技术人员焦头烂额。因此，Falcon横空出世，Falcon经过了数家公司2亿多指标的海量数据验证，在稳定性、易用性方面都没有问题。
Prometheus也支持大规模的集群部署，在2019年结束的阿里“双十一”活动中，阿里云中间件官方在《不一样的双11技术：阿里巴巴经济体云原生实践》电子书中宣布Prometheus在全球大促中经受住了洗礼。连阿里内部的鹰眼系统也发布了全托管版的Prometheus服务，解决了开源版本部署资源占用过大、监控节点数过多时的写入性能问题，对于大范围、多维度查询时查询速度过慢的问题也做了优化。优化后的Prometheus托管集群在阿里内部全面支持Service Mesh监控以及几个重量级的阿里云客户，许多优化点也反哺了社区。托管版的Prometheus兼容开源版本，在阿里云的容器服务上可以做到一键迁移到托管版。
如图1-15所示，面对海量的监控数据和性能压力，阿里使用了联邦（Federation）的架构将监控压力分担到多个层次的Prometheus并实现全局聚合。在联邦集群中，每个数据中心部署单独的Prometheus，用于采集当前数据中心监控数据，并由一个中心的Prometheus负责聚合多个数据中心的监控数据。
针对每个集群的OS指标（如节点资源CPU、内存、磁盘等水位以及网络吞吐）、元集群以及用户集群K8S master指标（如kube-apiserver、kube-controller-manager、kube-scheduler等）、K8S组件（如kubernetes-state-metrics、cadvisor）、etcd指标（如etcd写磁盘时间、DB size、Peer之间吞吐量）等，架构被分层为监控体系、告警体系和展示体系3部分。监控体系按照从元集群监控向中心监控汇聚的角度，呈现为树形结构，其可以细分为3层：
边缘Prometheus：为了有效监控元集群K8S和用户集群K8S的指标，避免网络配置的复杂性，将Prometheus下沉到每个元集群内。
级联Prometheus：级联Prometheus的作用在于汇聚多个区域的监控数据。级联Prometheus存在于每个大区域，例如中国区，欧洲美洲区、亚洲区。每个大区域内包含若干个具体的区域，例如北京、上海、东京等。随着每个大区域内集群规模的增长，大区域可以拆分成多个新的大区域，并始终维持每个大区域内有一个级联Prometheus，通过这种策略可以实现灵活的架构扩展和演进。
中心Prometheus：中心Prometheus用于连接所有的级联Prometheus，实现最终的数据聚合、全局视图和告警。为提高可靠性，中心Prometheus使用双活架构，也就是在不同可用区布置两个Prometheus中心节点，都连接相同的下一级Prometheus。
通过这样的架构部署模式，阿里的Prometheus从容应对了2019年“双十一”巨大流量带来的性能挑战。因此，性能是根据当前业务量做技术评估的一个重要因素。
3. 数据存储
Zabbix采用关系数据库保存，这极大限制了Zabbix采集的性能。Nagios和Open-Falcon都采用RDD数据存储，Open-Falcon还加入了一致性Hash算法分片数据，并且可以对接到OpenTSDB，而Prometheus自研了一套高性能的时序数据库，在V3版本可以达到每秒千万级别的数据存储，通过对接第三方时序数据库扩展历史数据的存储。
4. 服务发现
在当下这个微服务与容器化的时代，很多企业的监控系统中，所有组件及配置均实现了容器化并由Kubernetes编排。如果需要在任意Kubernetes集群里都实现一键部署，且需要变更系统时仅需修改相关编排文件，那么Prometheus就是不二的选择了。Prometheus的动态发现机制，不仅支持swarm原生集群，还支持Kubernetes容器集群的监控，它是目前容器监控最好的解决方案。
5. 运维管理
监控在运维中的核心地位不可动摇。
记得有一个老运维人员说过这么一句话：“监控如果真的做完美了，我们运维也就可以高枕无忧了，每天可以就看看监控数据，然后各种‘挑刺儿’就行了。”一言以蔽之，监控系统需要以人为本，让人使用、管理起来方便。
比如小米在研发Open-Falcon之前就面临着如下运维管理问题。
管理成本高昂。为了让Zabbix压力小一点，整个公司搭建了多套Zabbix，比如多看自己用一套、电商自己用一套、米聊自己用一套，如果要做一些公司级别的统计，需要去多个数据源拉取数据。每套Zabbix都得有运维人员跟进，人力成本上升。
Zabbix有易用性问题。比如Zabbix的模板是不支持继承的，机器分组也是扁平化的，监控策略不容易复用。Zabbix要采集哪些数据，是需要在服务器端做手工配置的，而这是一个本该省去的操作。
微服务监控有四大难点，分别是：
配置难。监控对象动态可变，无法进行预先配置。
融合难。监控范围非常繁杂，各类监控难以互相融合。
排查难。微服务实例间的调用关系非常复杂，故障排查会很困难。
建模难。微服务架构仍在快速发展，难以抽象出稳定的通用监控模型。
很多负责监控相关工作的读者在实际工作中会遇到告警的对接、告警的收敛、告警的可用性等问题，这些都是运维管理中需要考虑的问题。而Prometheus在这些方面都有解决方案。
2018年，爱可生数据库平台监控系统在数据库沙龙专场做过一次案例分享，这个案例对运维过程中的告警对接、收敛、可用性做了形象化的展示。
我们是一家乙方公司，通常服务于各种甲方，不同甲方有不同的需求。比如甲方如果有自己的监控系统，就会希望我们的监控系统能与它的监控系统进行对接。在与甲方接触过程中，我们曾遇到过这样的客户。有一天客户跟我们说他最新买的苹果手机被他换掉了，因为他的手机经常会死机，死机的原因就是他收到了太多的告警，最后他专门买了一个安卓手机用来接收告警。所以我们的第二个告警需求是，将告警进行收敛。假如长时间没有收到告警消息，你们是会认为自己的系统运行得很完美，还是会担心告警系统挂掉了？如果是告警系统挂掉了，不能及时把告警发出来，那么最后这个锅到底由谁来背？大家都不希望背锅，所以第三个告警问题是解决告警的可用性问题。
当然，运维管理还需要考虑到Web功能、画图展示、默认监控等。
以Nagios和Zabbix为例。一般来说，Nagios更容易上手，但Zabbix界面更美观。Zabbix的画图功能用得更舒服，且Zabbix会有很多默认监控，这给运维管理带来非常省心、舒适的感觉，Zabbix后续的批量监控实施也更为简单。对于Nagios，如果写好自动化脚本，处理相关工作也很简单，问题在于写自动化脚本很费神。
Prometheus虽然本身的画图展示功能非常一般，但是它借用了开源的产品Grafana，结合Grafana后，Prometheus的画图功能实现了质的突破。
6. 开发语言
从开发语言来看，为了应对高并发和快速迭代的需求，监控系统的开发语言已经从C语言、C++语言、Java语言转移到了Go语言阵营，以Open-Falcon和Prometheus为代表。
Go语言凭借简单的语法和优雅的并发，在目前云原生场景下使用得越来越广泛。而且，目前在国内市场上，C语言主要用于单片机等底层开发领域，从中间件开发岗位需求和目前大量Java人员转型来看，Go语言在监控领域的活力还是非常高的。
从全世界来看，我国是Go语言爱好者最多的国家。在我国，Go语言开发者主要集中在北京、深圳、上海3个城市。在北京，由于做云计算的公司很多，不论是面向市场的公有云还是自建自用的私有云，开放平台技术、容器技术、集群管理技术、微服务和Serverless技术等都是Go语言擅长的方向。Go语言的应用主要集中在如下方向。
服务器编程。以前使用C或者C++做的那些事情，现在用Go来做很合适，例如处理日志、数据打包、虚拟机处理、文件系统等。
脚本编程。完全可以把Go当作Python来用，日常的各种自动化任务、小工具等都非常适合使用Go编写。
网络编程。这一块目前应用最广，包括Web应用、API应用、下载应用。
云平台。目前国外很多云平台都采用Go开发，CloudFoundy的部分组件、前VMware的技术总监自己出来做的Apcera云平台以及大名鼎鼎的Docker都是用Go开发的。
如表1-4所示，Go语言的项目中绝大多数可以在GitHub上搜到，在那里可以了解每个项目的实际功能、架构和使用场景，由于本书的主题和篇幅问题，这里不再展开。
7. 社区力度及生态发展
对于目前流行的编程语言，如Java、Python，如果在使用过程中遇到了一些异常，基本上可以借助搜索引擎来解决，因为一个产品用的人越多，暴露的坑也就越多，对应的解决方案也就越多。这种方法对于监控系统同样适用，这可以让你“站在巨人的肩膀上”解决遇到的问题。
Zabbix、Nagios、Ganglia的确都是老牌的监控系统，它们分别在1997、1998、2001年左右出现，都具有系统稳定、成熟度较高等特点。Open-Falcon和Prometheus都是最近几年才出现的，虽然功能还在不断迭代和更新，但是它们借鉴了很多老牌监控系统的经验。尤其是Prometheus，作为CNCF第二个毕业的作品，其Google搜索量和GitHub活跃度非常高。Prometheus也是直接对接K8S环境的，非常适合云上使用。
8. 误区探讨
伴随着企业的发展，企业内部的监控往往会经历无监控、半自动脚本监控、自动化监控、集群式监控、全方位立体监控等阶段。未来的监控，会朝着链路化、全息化、立体化、低成本、自愈性、无人值守等方向发展。
在进行监控系统选型之前可以先问自己一个问题：是否真的需要一个监控？
在搞清楚这个问题之后，还可以继续问自己一个问题：是否需要自己维护一套监控？很多初创型公司为了节省成本会选择直接购买与监控有关的云服务，自己只需要关注如何使用即可，其余的都可以外包出去。也有些公司采用内监控和外监控结合的形式，内监控是企业自己搭建自用监控系统，外监控是用外来的商业监控产品对产品的最外层接口和用户行为进行宏观监控。
很多人面对监控系统时会有一种自研的冲动，自研会有交接问题、KPI问题。如果之前自研的人不对监控系统进行维护了，会有什么问题？这些自研系统的交接会不会给新人挖坑般的噩梦体验？是否真的有自研的必要？如果不是KPI的压迫可以考虑如下问题：目前市面上的监控系统是否真的都无法满足目前业务需求？团队的核心竞争力真的就是监控系统吗？是否有足够的能力、人力、财力、精力来支持自研？
监控选型时切忌一味地追求性能或者功能，性能可以优化，功能可以二次开发。如果要在功能和性能方面做一个抉择的话，那么首选性能，因为总体上来说，性能优化的空间没有功能扩展的空间大。然而对于长期发展而言，生态又比性能以及功能都重要。
监控系统选型还有一个标准，就是尽量贴合团队的自身技术体系栈，比如我们团队是中间件方向、云原生方向，那么Java和Go语言就是团队自身的技术体系栈。在这个语言的基础上，团队可以合作、奋斗，拿出更多、更好、更棒的成果。
企业处在不同的成长时期也可以选择不一样的监控系统，CMDB+Zabbix在一定的量级以内还是非常靠谱和稳定的，一台机器就可以完成很多的监控业务。如果业务和技术并没有达到那个量级且中长期达不到那个量级，投入大量人力和物力实现的“巨无霸”，真的非常有意义和价值吗？很多经验丰富的技术人员用过的监控系统应该不下10种，每种监控工具都有自己的优缺点，并不是越新的技术就越好，不能盲目跟风，没有最好的，只有最合适的。Nagios虽然历史悠久，但是在实际运维中依然有它独立存在的意义，在一些基本的监控项目中甚至比高大上的Prometheus更加方便。比如针对最基本的监控ping和telnet port，Prometheus有一个up函数，但是其只有两个状态up和down，而Nagios对这种状态比较少的监控更为简单直接。盲目追新并不是监控选型的态度，专业的监控架构是综合实际使用情况去做设计、做规划的，可以根据实际情况结合使用多种监控。
十万的用户对应十万的架构方案，百万的用户对应百万的架构方案，千万的用户对应千万的架构方案，亿级的用户对应亿级的架构方案。这就好比我们团队中的一个成员在开会时提出的：“现在我维护的网关系统界面不太好看，我想请前端人员帮我美化一下。”我直接回复：“现在应该没有人接入你的网关吧？当前第一要务是接入，美化的事情并没有接入重要，当前也没有必要浪费前端资源。”什么阶段就应该做什么阶段的事情。
最后要说的就是不要迷信权威，不能人云亦云。不是别人说好就是好，一定要自己亲身试验过才有发言权，实践出真知，大家可以参见我在个人微信公众号“工匠人生”上发布的Prometheus作者的文章《PromCon上VictoriaMetrics和Prometheus的权威性能和正确性评估》的译文。
推荐语：本书被誉为Prometheus“百科全书”，可以指导读者快速搭建一个Prometheus监控系统并将其应用到实际工作中，囊括私有云、公有云、混合云环境下的大量案例。针对运维人员，分享Prometheus对接各种云原生应用并实现事前预警、事中报警、事后提供翔实数据的方法，针对开发人员，给出了Prometheus主要组件的源码分析以及部分功能的二次开发实现。从入门知识到高级技巧，全面解读PromQL，并给出上百个PromQL实际案例。以附录的形式给出端口、数据类型、选择器、指标类型、PromQL内置函数等实际工作中需要时常查阅的内容。
福利赠书：
文末留言对云原生监控的一些心得体会，截止到11月28日12点，点赞数最高的前三名获得图书一本
加入技术琐话读者群讨论，请在公众号回复关键词：读者群。
往期推荐
技术琐话
以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。本号由坐馆老司机技术团队维护。